Tagging commits?

[dgikiller]

Hi, I am a mantainer of a repository of Sabayon Linux based Distro and I want to ask you if it's possible add more version tag to make this set of icon more maintainable from our side.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Foggalong]

Hi @dgikiller. Sorry, but for our desktop icon themes we follow the rolling release model meaning there are no version tags. The only exception is when we do a major redesign of all the icons in the theme, then we bump the number. What is it you're having problems with?

[dgikiller]

I asked because we are using a tool for automatic scanning of updates. Without tags I need to set manually the commit to select a version and then ship it in our repository, with defined versions this work could be faster and make your icons more available for users of any distribution.

[Foggalong]

Ah, I see! For Ubuntu, Arch, and (I think) SUSE and Fedora we just have them set to either update daily or whenever a new commit is made, hence we've never had to bother with tags. Are either of those an option to you?

[Foggalong]

Anywho it's unlikely that we're going to switch to using tags, sorry. It's extra work on an already busy ship for us, and doesn't really work with the release schedule we follow. I hope one of the methods mentioned above works for you though!

[sspreitzer]

What about reopening this conversation? Would an automatic time based tagging like every half a year a feasable option? Like for say tag: 2015.11 ?

It can be rather annoying for Desktop users that they are being informed ever second day about an update on the very same packages of some days ago. Even speaking of enterprise Linuxes it wouldnt be a desired behaviour? Could we think of having an automatism that would mean no efforts for numixproject plus version reliability for the OS packagers out there?

( I would be willing to solve this )

[Foggalong]

If the user (or packages) desires updates at a greater interval it'd be much easier to install via git and then just pull when required. I'd sooner not clutter the git with tags if it can be avoided

[sspreitzer]

Sure. And they could have both. For example automatica Fedora Linux system packages of numix not older then six months and/or manual git based. What is your reason in not accepting git tags when you will have absolutely no efforts with them as everything can be automatic? If you dont trust my proposal i can fork this repo and show you how?

[Foggalong]

It's not that I don't trust you (really I do), it's just that it messes up the current convention of new design new tag. I don't really understand the way copr packaging works, but is there a reason it can't operate based on time intervals like the PPA and AUR do?

[sspreitzer]

Ah okay. Thank you :) What i am speaking of is the official repository of Fedora Linux, CentOS and Red Hat Enterprise Linux. Not the copr. To get there some kind of release versioning (tagging) would be highly appreciated.

Anyhow i dont know about ppa and aur. I will take a closer look on them and will come back here when i am wiser. ;)

[Foggalong]

Wait... you can get it into the Fedora repos!!!!!!!!! :D

[sspreitzer]

Yes, that is my intention. :+1: :smile:

That is also why I was speaking of a cycle of 6 months as it is Fedora Linux official release cycle.

[mudler]

@Foggalong this is not actually a fair behavior. Now that RedHat asks for tags are you going to think about it? it was so hard to tag a repository? i don't think so. Comparing to Aur or PPA as a "working" mechanism is not actually a good reason to do not tag. Gentoo is more strict about that, just because QA comes first. And we try to avoid as much as possible using github directly for obvious reasons (fails, downtimes, and maybe leveraging the whole mirror system that we have? ). Just my 2c

[dgikiller]

@mudler quote, and don't forget tree rebase that break also manually tagged versions' rebuild. Upstream tags can avoid a lot of mess.

[Foggalong]

@mudler I gave it thought when the Gentoo packager asked and the answer then was no. I'm now giving it the same thought for Fedora, but that doesn't mean the answer will automatically be yes. Just Bad in mind that a significantly higher proportion of our user base uses Fedora based distros than use Gentoo based ones (which is why we used to have an official copr repo).

[mudler]

@Foggalong it doesn't seem a proper justification to me. If you want your icons only on Fedora, that's your way for doing it. So, If you don't use such distributions you are not going to support them? This is crazy. You could also even tag manually once a year and we could also work with that. Tagging isn't taking so much time, all of this sounds so absurd to me.

Also, dont' forget that a lot of pandas will die if you don't do it :smile:

[sspreitzer]

@Foggalong i am willing to take all the release tagging efforts off your shoulders, so you would not have to think about it at any time. It would be an automated process that tags the icon repositories about every 3 or 6 months so Linux OS packagers like @dgikiller, @mudler and me can create respective packages.

Having tags in a git repository is not additional clutter people would have to worry of, they are referencers to commits in the repository. When people dont explicitly want to work with a tag, they will not have a different experience of what they have when not using tags. Git tags are not a barrier.

If this is still inconvenient, we could also think of that i fork the icon repositories in my Github namespace and do the tagging there and package authors can use them as a source. Which i would not recommend as it is more a workaround then a satisfying solution.

[Foggalong]

@mudler I didn't say that I use it (though I do have Korora on my laptop, all my Numix installations are git based so it's moot), I said that a lot of Numix users use it. It's our third most popular distribution after Ubuntu and Arch by a long way.

Up to now every distro that's needed packaging has been fine just using raw git and doing releases triggered by time intervals or new commits. Now it's emerging that multiple distros would benefit from a tag system it's worth considering again.

---

@sspreitzer It's not so much the clutter the every day user has to worry about, its myself and the other designers. Up to now we've used tags to reference redesigns of a theme and to switch to this system would mean a departure from that.

Also, agreed that forking to a GitHub namespace shouldn't be the solution.

[sspreitzer]

@Foggalong When you do a redesign you are creating a branch and not a tag. When your branch is the desired outcome you can merge it in via (as Github works) a Pull request. This has nothing to do with tags. (though both are references to commits)

Can you please make a suggestion of a solution that will fit the Designers and the OS Packagers requirements?

If there is no feasable way, the only thing to do would be the proposed workarround of forking and thus outsorcing the tags from your repositories. @mudler and @dgikiller what do you think about forking the repos and outsourcing the tagging?

[Foggalong]

@sspreitzer the redesigns are tags, not branches. Check the release page

[mudler]

@Foggalong : @sspreitzer was just suggesting to you how to properly use tags, your case requires working with branch in that way, not with tags. To me you are not using them for the correct reason, also because in that way i dunno how much tags are you going to have.

@sspreitzer everything that will work is accepted at this point, since @Foggalong doesn't seem to change his mind about this. We have worked so far with workarounds, another one doesn't makes me really enthusiast: but if that's the only way it's still better than punting to commits. Thank you for your efforts :+1: if you are doing it i'll switch the ebuilds to punt at your repository

[Foggalong]

@mudler The redesign tags aren't for a new piece of code being developed though with the intention of merging it in, it's for an old version of the same product. While we use branches for developing the new design, when it's done and merged we use tags to mark the final point of the old design.

I also didn't say I wasn't going to change my mind - I quite clearly said 2 comments above that I was reconsidering.

[mudler]

@Foggalong this is just a odd way to work, and it is not common. If all projects did like you, packagers would be forced to always use live specfiles to build the package. That's it, don't let turn this in flame war, we are just trying to helping you deliver your icon packs better here.

Have you ever heard about gitflow?

IMHO it's better to put different "products" in different repositories. If you are afraid to lose the history, you just have to pull the old repository commits inside the new, nothing really difficult.

So please make a suggestion instead of explaining how do you work, this approach is working for you designers, but not for us, packagers. You are not providing a solution here.

[Foggalong]

It's not common for open source projects to use this model, but most open source projects aren't design ones. Again, I don't think you're understanding what I've said - the tag isn't for a different product just an earlier release of the same one (the equivalent of a vA release in A.B.C of software).

I'm not intending this to be a flame war, but you came in aggressively saying we weren't being fair to you and that the way we've done things is wrong (despite at the same time making multiple errors in your explanation of the way we do things). Hence I'm just explaining why and how we do what we do, with the comment (restated explicitly for the third time now) that I'm reconsidering our methods.

[mudler]

@Foggalong i understood you. don't worry about that. Still i haven't seen yet a model like yours now. Tagging is not a barrier.

So what are your ideas ? how we can solve the problem? still i see only @sspreitzer has proposed a valid solution. And since the solution is a workaround, this means there is something wrong on how you deal things, don't you? Please take time to consider, do not answer just because you feel attacked. i'm not attacking you, just suggesting new ways on how to deal with things.

PM side, your approach is wrong. that's it

[Foggalong]

@mudler If you understood, why the errors? :P

And now for the 4th time, I'm reconsidering. Something like this will need to be discussed since it's a change to all of the design repos (rather than just this one), and there's more than just me on the team managing these repos.

[mudler]

@Foggalong double quotes was there for a reason :) "products": if you are major changing your designs, you could split up in different packages? Or tagging them anyway? i don't actually know what your workflow of a product is

Having just one tag have a particular purpose? why is that so? This is like not-using a feature!

I'm glad to see anyway that you only reconsider when asking is redhat :) Your users are Linux users, we (@sabayon) choose for example to ship your icon set as default, this means that we are bringing more users to you too! why should be that make any difference?

[Foggalong]

To all: if you want to skip this part of the comment you can, it's just me rambling a bit about the current workflow and changes in platform traction. For the important bit skip to _Possible Solution_

---

@mudler We do use a different package for Bevel because that particular iteration of the theme has popularity in its own right. We tried doing that with a few different themes (like Square Legacy) but they never really got the traction needed.

It's probably not very clear just looking at Circle because it's only had 2 iterations (Bevel and current), and even less clear just looking at Base (only 1 iteration). The use seems a bit clearer when you look at uTouch which has now been through 3 iterations (Original, Boogaloo, current) with a 4th being worked on as we speak.

I didn't know that @sabayon used our theme, that's really cool! I keep meaning to add a section of the site for distributions that we work with / use our themes. And yeah it definitely makes a difference. More people on a platform using our icons give us motivation to ramp up support for it, which then in turn will bring in more users. We recently had this with KDE when we added a few hundred KDE specific icons to the pack, which increased the number of people using it on KDE, which has meant we have more KDE specific issues reported.

---

Possible Solution

I've just been thinking about how we use the vA in vA.B.C for tagging major redesigns. We could possibly extend this usage so that we start using the B to denote major fixes (the recent panel problem, aligning mimetypes, recolouring status icons) and then have C be incremented weekly for fortnightly. An increment in B would reset C to zero, and same for A with B & C.

That way packages can decide to either package for the major redesigns (every A), the major fixes (every A.B), or based on time intervals (A.B.C). What are peoples thoughts on this?

[mudler]

:beers: :+1: @Foggalong w00t!

that would make anyone happy i think! (PM included!) We are shipping your icon set with the GNOME flavour (well, we tested with kde too, but we felt wasn't totally integrated). i'd be glad to ship your icons also on our KDE flavour as well!

[sspreitzer]

@Foggalong: This sounds like a good approach. My personal opinion is to even skip the C part as it is too frequent and people can also pick the newest git which would almost be equal. As you are stepping up and also into the materia do i assume correctly that you will manage the tags (do the tagging) so OS Packagers can steadily rely on it?

Usually there is a common rule for OS Packagers that they will rebuild the OS Package for a newer version everytime a newer version is released. So if you are doing fortnightly releases it would be too frequent (for OS Packagers).

In my humble opinion vA.B works perfectly and i agree with that. But only if you are steadily tagging it. You are the expert in the field who can distinguish what what differs a 1.2 from a 1.1. I cannot distinguish it. Thus the efforts on tagging would be on your shoulders.

Or we can go a YYYY.MM (eg. 2015.11) approach which i can easily automate and take off the efforts from your shoulders.

@Foggalong; Do you agree in one of those schemes (which one?) and do we have a consent?

[Foggalong]

@mudler Yeah, there's still a lot of work to be done before KDE support is where we'd like it to be. We currently have an issue open in base which is a master list of requested KDE icons and it's hundreds long.

[Foggalong]

@sspreitzer As I say, I'm not the only guy on the team and not the only dev who'll be affected by the change so I'll have to talk it through with a few people first. Will get back to you asap

[sspreitzer]

@Foggalong; Yes that i totally understand. Its also seen that you are very utilized by numixproject. Which makes the numix icons nice and shiny: :smile: Very cool of you, thank you very much for your work!

When do you think there can be an answer available? I would say until monday (23rd Nov. 2015)? Do you have a mailing list where maybe @mudler, @dgikiller and i could participate in the communication, being available for questions?

@dgikiller + @mudler: Thank you also for input and contribution. Personally i am very happy to see that we are coming to a solution which will work. :+1: :beers:

[mudler]

@sspreitzer thanks to you also for reopening this discussion! :beers: I'm very glad to see that we found a solution :) and yes, totally, a mailing list would be great!

Indeed the .C versioning it is not strictly necessary, a "monthly" updated would be just fine

[Foggalong]

@sspreitzer We don't have any public mailing lists or chats, sorry! We do most of the discussion either in GitHub threads or on Telegram. I'll try and get the guys to come here to continue the discussion :) I can't say for certain when the answer will be given by, but it probably won't be as early as Monday

@mudler Reasoning for the .C: we aren't always adding major fixes to the theme, the majority of commits that happen are just bog standard icon additions. Just using A.B means that sometimes it could be a long time between a new version being releases and users could be missing out on 100s of new icons. With the .C incrementing on the end (be it weekly, fortnightly, or monthly) users can still get those new icons before another major fix comes along

[sspreitzer]

@Foggalong so there we touch the root of the problem. If you can not tag any different then most recently, then we are back to time based tags.

If there is not a reliable and committed statement (who is in charge of doing what and when) until latest monday that will enable OS Packagers to release as of common release practises i will start to maintain a fork which will do so.

[Foggalong]

@sspreitzer why the rush on doing it for Monday? If we're going to do this we're going to do it right

[satya164]

I think tagging releases is certainly the way to go. We can tag releases once a week or so.

[Foggalong]

CC: @tech4david, maintainer of uTouch

[mudler]

Ping @Foggalong , any news on that?

[Foggalong]

@mudler @dgikiller @sspreitzer

Hey all! Thanks to the new Numix Core build system, this is now fixed! In the packaging repo we now have releases and tags set up and ready to go. For now I'll be using weekly builds with the system and we'll see how that works :)