Labels/Tagging Feature - Reloaded

[Lundh, Gustaf]

Hi Gerrit Devs,

 

A few years ago, our engineers implemented a great (IMHO) Label/Tagging system for Gerrit [1]. This feature would allow the users to append generic string based metadata to changes via UI/SSH/RestAPI.

 

[1] https://gerrit-review.googlesource.com/#/q/topic:edit-labels-in-change-screen

 

The “tags” (sorry, I know the word is reserved for other purposes) or labels could be used for searches (and dashboards), classifying changes with company specific data or helping teams organizing their work/workflow.

 

Examples:

* Tagging changes with build labels.

* Tying Gerrit to an ALM, allowing us to create dashboards for high priority changes thus making it easier for teams to plan their reviews.

* Help teams tag changes with meta data from the backlog stories: Prio/Size/Sprint No/Issue Nr/Etc.

* Classify changes around affected areas. E.g. Core, UI, Backend etc.

* Allowing the Gerrit-Trigger Plug-In to tag chances currently building or completed building.

 

I made a quick mockup how the feature could look in the new change screen:

http://i.imgur.com/OgJhG8v.png

 

And when adding new tags/labels:

http://i.imgur.com/T1azkvk.png

 

I am certain teams will find other and even better ways to use the tagging system. If the feature is not wanted by the organization, reading/writing tagging rights could be controlled and disabled through capabilities.

 

The first time around, this feature was pretty much completed but never merged. One of the reasons was the need for a new database schema, which was not really popular since work had just begun to migrate from a database approach to storing meta data in Gits.

 

However, nowadays it seems reasonable to implement the feature using Git Notes tied to the Change and then index the data using the secondary index, like Lucene or Solr.

 

So before we restart the work on this feature:

* Is this something the community want to see in Gerrit?

* Is there any reason not to make it a core functionality?

* Is the UI design reasonable?

 

Please give us your thoughts on this.

 

Cheers

Gustaf

 

 

[Luca Milanesio]

Hey Gustaf,

I really like the idea ... just don't like the "tags" but please call them "labels" ;-)

It *has* to be a core feature IMHO and *has* to be included in the Gerrit filters, so that one can selectively navigate through the changes in a "labelled" way.

The UI seems reasonable to start, no objections.

Possibly would be nice in the "changes" list to have a list of labels to select (default all selected) so that one can enable / disable the display of changes belonging to certain labels.

Luca.

-- 
-- 
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lundh, Gustaf]

Hi Luca,

 

Thanks for your comments!

 

> Possibly would be nice in the "changes" list to have a list of labels to select (default all selected) so that one can enable / disable the display of changes belonging to certain labels.

 

Sorry, I’m not really sure exactly what you mean here. Could you perhaps attach a sketch or elaborate a little bit?

 

Gustaf

[Luca Milanesio]

Hi Gustaf,

from my (social) point of view of Code Review, it is like the "blog" of your project.

In order to understand what's going on on Gerrit, I typically go through the changes list as I would read a blog ;-)

Changes are the chapters organised sometimes in topics and your proposed "labels" are exactly the labelling of the Blog posts.

Having then a "side" panels like this (with "Tags" word replaced by "Label"):

Possibly auto-hiding so that would not take important column space in the changes list :-)

The Label text size is proportional to the number of changes with that label included.

What do you think ?

Luca.

[Lundh, Gustaf]

Thanks. Perfectly clear now.

 

I agree, a label cloud (I think that’s the common name for that feature) makes sense and would serve as a nice starting point for browsing changes.

 

/Gustaf

[Luca Milanesio]

"Label cloud" ... I had on the tip of my tongue ;-)

Luca.

On 8 Aug 2014, at 08:48, Lundh, Gustaf <Gustaf...@sonymobile.com> wrote:

Thanks. Perfectly clear now.

 

I agree, a label cloud (I think that’s the common name for that feature) makes sense and would serve as a nice starting point for browsing changes.

 

/Gustaf

 

 

 

From: Luca Milanesio [mailto:luca.mi...@gmail.com] 
Sent: den 8 augusti 2014 09:39
To: Lundh, Gustaf
Cc: repo-d...@googlegroups.com
Subject: Re: Labels/Tagging Feature - Reloaded

 

Hi Gustaf,

from my (social) point of view of Code Review, it is like the "blog" of your project.

In order to understand what's going on on Gerrit, I typically go through the changes list as I would read a blog ;-)

 

Changes are the chapters organised sometimes in topics and your proposed "labels" are exactly the labelling of the Blog posts.

 

Having then a "side" panels like this (with "Tags" word replaced by "Label"):

 

<image001.png>

[Martin Fick]

On Thursday, August 07, 2014 04:02:01 PM Lundh, Gustaf
wrote:

> Examples:
> * Tagging changes with build labels.
> * Tying Gerrit to an ALM, allowing us to create dashboards
> for high priority changes thus making it easier for teams
> to plan their reviews. * Help teams tag changes with meta
> data from the backlog stories: Prio/Size/Sprint No/Issue
> Nr/Etc. * Classify changes around affected areas. E.g.
> Core, UI, Backend etc. * Allowing the Gerrit-Trigger
> Plug-In to tag chances currently building or completed
> building.
>
> I made a quick mockup how the feature could look in the
> new change screen: http://i.imgur.com/OgJhG8v.png
>
> And when adding new tags/labels:
> http://i.imgur.com/T1azkvk.png
>
> I am certain teams will find other and even better ways to
> use the tagging system. If the feature is not wanted by
> the organization, reading/writing tagging rights could be
> controlled and disabled through capabilities.

(I will use the term labels to disambiguate from git tags)

I think most of us definitely want labels, good to see you
thinking about them again!

I suspect you are asking because you want to get a design
that people are going to agree to before you start
implementing again.

I would like to propose that labels be designed with
namespaces that are divided along user/group and potentially
private/public boundaries. I think this approach lends
itself naturally to a simple ACL system for labels that
requires no global administration, and provides the context
that labels need to help give them "meaning" in a way that
is both easy to manage and reason about for all users of the
system.

Let me start with a simple example to first illustrate what I
mean by "giving meaning to labels". Let's think of a
specific label: the "important" label. I want to label the
changes that are important to me. So does Joe. When I
search for "important" changes, I don't want my search to
return the changes that Joe thinks are important (and likely
vice versa). But what about if Joe and I work on a team
together, and we as a team have an idea of changes that are
important? We likely want a way to mark changes that are
important to our team independently of our personal lists of
important changes. I think that making this easy should be
a primary design goal of labels.

What we proposed in the past:
---------------------------------------
In the past we talked about using the gerrit ACL system to
manage who can apply labels. However, the gerrit ACL system
does not actually support a way to easily subdivide a label
namespace, it only allows global capabilities and
project/ref based ACLs.

Why capabilities do not fit well:
---------------------------------------
For starters, it would be shameful to have a label system
that does not allow all/any user to label things, and this
is what using global capabilities likely means. It means
splitting users into 2 categories, those with the power to
label changes, and those without it. It also means that the
meaning of a label is global to a server and thus likely
will need to get pushed down from the top of an
organization.

Why project/refs do not fit well:
---------------------------------------
Project/ref boundaries do not likely provide useful
boundaries for the meaning of labels. While I can imagine 2
unrelated projects with leads that want to define the meaning
of the "important" label, benefiting from a project/ref
boundary slightly, even for those leads it will be clunky to
use their "important" labels. They will need to narrow down
their searches to specific project/refs to get the changes
they care about. As for ordinary users to take advantages
of those 2 sets of labels, how will they know how to
separate those 2 different sets without intimate knowledge of
the ACLs on those project/refs?

What I think would work better:
---------------------------------------
I think that a user (and later a group) centric approach to
labels would be much more useful. If you give each user
control over their label namespace, there is no need to
administer ACLs at all, they are "auto-managed". With user
labels, meaning is local to the user, not global. Users can
label and search for their lables "at will" easily. No one
would need to define that they can do this, and whether
someone else could apply their labels or not.

From an ACL standpoint, the only thing that you might want
to add to this feature would be the concept of
private/public labels. If you start assuming all labels are
public (but user namespaced), then privacy can be added
later as a special feature (so I can label changes
unimportant without offending anyone!), and privacy can be
managed by individuals (or groups later).

In the beginning, to give "shared" meaning to labels,
specific automation users could be used. So a CI system user
could store common team labels. However, eventually having
group based labels would likely fill this role better. A
group label would work like a user label, but any member of
the group would be able to apply the label. With group
labels, it becomes possible to have multiple individuals
controlling the same label, and it gives a nice way of
giving context specific meaning to shared labels. Again,
this can happen without having to administer ACLs.

Why this might be important now:
-------------------------------------------
Aside from the UI issues related to namespacing , this might
be important in order to figure out how to put labels into
ref notes. When desigining a way to store data in a git
repo you have to decide what refs to store data on, the
decision about what ref to use likely needs to consider who
can read and write that ref. This means that unfortunately
it might be important to figure out how to control read and
write on labels before committing to a way to store the
label in git.

> However, nowadays it seems reasonable to implement the
> feature using Git Notes tied to the Change and then index
> the data using the secondary index, like Lucene or Solr.
>
> So before we restart the work on this feature:
> * Is this something the community want to see in Gerrit?

Of course! :)

> * Is there any reason not to make it a core functionality?

No. although I might ask the other question, which we
probably should start doing more from now on, is there any
reason for it not to be a plugin? In order to make it a
plugin, we would need to expose more APIs for plugins, so it
would only delay this feature more (which I do not propose),
but it would also make Gerrit more powerful.

> * Is the UI design reasonable?

Yes,

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Lundh, Gustaf]

Hi Martin,

Thanks for your comments! Greatly appreciated! After discussing through your reply with Sven Selberg (who will co dev this feature), I will try to address your concerns and ideas.

> (I will use the term labels to disambiguate from git tags)

And I will too.

> I suspect you are asking because you want to get a design that people are going to agree to before you start implementing again.

Absolutely, I'm trying to minimize redundant work.

> I would like to propose that labels be designed with namespaces that are divided along user/group and potentially private/public boundaries. I think this approach lends itself naturally to a simple ACL system for labels that requires no global administration, and provides the context that labels need to help give them "meaning" in a way that is both easy to manage and reason about for all users of the system.

[...]

> What I think would work better:

[...]

It is still not fully clear to me, exactly how this could be solved in a way that makes complete sense without cluttering the UI for the end-user. How would a user be able to differentiate between public, private, individual and/or group label(s) when adding (check boxes?) or searching? How should a user choose the label group in a way that makes sense in an LDAP-world where every user is part of 100s of groups?

I understand the need for a users to have private labels to help organize themselves, but since private labels are not one of the more prioritized business cases for us, I have a proposal; My suggestion is that we develop a public label system similar to what we proposed using the ACLs (some Leads/Teams/Projects may want to reserve the labels for themselves on certain refs, without other users interfering) and store them in the project.git/changes/ namespace, similar to how approvals will be handled in the NoteDB.

In the future, we (or someone else) may extend it to individual private labels. In that case it would make much more sense to place those labels in All-Users.git in a similar way to how draft comments will be stored [1]:

https://gerrit-review.googlesource.com/#/c/58572/

I do not see a future feature conflict here.

>> * Is there any reason not to make it a core functionality?

> No. although I might ask the other question, which we probably should start doing more from now on, is there any reason for it not to be a plugin? In order to make it a plugin, we would need to expose more APIs for plugins, so it would only delay this feature more (which I do not propose), but it would also make Gerrit more powerful.

Exactly. I also think a plug-in approach would delay the feature much further. E.g. taking the plug-in route would be a much more costly investment (time wise) for my team. So if the Label-feature is generally wanted, I prefer to go a more direct way of implementing it directly into Gerrit, without spending lots of time building various extension points and doing heavy refactoring. When completed, first then start building extension points upon that, but only where it really makes sense.

>> * Is the UI design reasonable?

> Yes,

Cool.

On a further note, I just got back from being on parental leave for the last 6 months, so I'm not totally up to date on the Gerrit code base. I thought the migration from SQL to Git NoteDB was close to completed, but it seems to be quite some work left on it. Not sure if it is a good idea to start developing this feature in parallel while Dave and Yacob continue their work on the NoteDB stuff, or if I should wait starting on this feature a little while more. Any comments on the state of NoteDB?

Best regards
Gustaf

-----Original Message-----
From: Martin Fick [mailto:mf...@codeaurora.org]
Sent: den 9 augusti 2014 00:24
To: repo-d...@googlegroups.com
Cc: Lundh, Gustaf
Subject: Re: Labels/Tagging Feature - Reloaded

[Martin Fick]

On Monday, August 11, 2014 04:51:33 PM Lundh, Gustaf wrote:
> > I would like to propose that labels be designed with
> > namespaces that are divided along user/group and
> > potentially private/public boundaries. I think this
> > approach lends itself naturally to a simple ACL system
> > for labels that requires no global administration, and
> > provides the context that labels need to help give them
> > "meaning" in a way that is both easy to manage and
> > reason about for all users of the system.
> [...]
>
> > What I think would work better:
> [...]
>
> It is still not fully clear to me, exactly how this could
> be solved in a way that makes complete sense without
> cluttering the UI for the end-user. How would a user be
> able to differentiate between public, private, individual
> and/or group label(s) when adding (check boxes?) or
> searching?

Good questions, and indeed I think part of the challenge of
making labels useable. I think these are real problems
with any label approach. With the global namespace solution
I think these problems are being delayed to later be solved
by every Gerrit installation.

I don't have all the answers, however I will outline what I
might imagine would work fairly well. I first imagine the
current user's labels as the most important labels to them,
so they should appear on a change, something like:

My Labels[+] - Important [x] FancyFeature [x]

The [+] allows a user to add their own labels, the [x]
allows them to delete them. Clicking on the [+] likely
provides a text box to type a new label into (no need to
define a list of labels, any text could be added as a label
since it is limited to a single namespace)


Next, since other users' labels are likely less important to
each other, I imagine a way to indicate that some exist, but
perhaps they are "collapsed" and require a click to display.
Maybe like this:

My Labels[+] - Important [x] FancyFeature [x]
User Labels - [...]

By clicking on the [...] link, it would expand to something
like:

My Labels[+] - Important [x] FancyFeature [x]
User Lables - Joe: Important, Ready
Jim: Ignore
Jenkins: NeedsRerun

Obviously there is no ability to edit other users' labels.


Group labels could be similar to user labels. Maybe there
is some magic threshold in both user and group cases where
the rows get auto expanded to avoid having to click to see
them? Here is an example expanded group case:

My Labels[+] - Important [x] FancyFeature [x]
User Labels - [...]
Group Labels[+] - Android: HighPriority Ready

The group [+] allows a user to add a new group label to one
of their groups (by first picking a group).

If the user is in a displayed group, then perhaps add edit
abilities directly like this:

GroupLabels [+] - Android[+]: HighPriority [x] Ready[x]


As for privacy concepts, simply don't display private labels
that a user can't see. Managing the privacy would be done
not on a change, but rather in the setting for a user under
a label tab. A label tab could also be added to each group
to manage group label privacy.


For searching, I imagine if I type "label:important" it
would only search my labels. If I want to search Joe's
public labels, I would do something like
"label:user=Joe,important" (or maybe "label:Joe=important"
as a shortcut). And for group labels I might do
"label:group=Android,HighPriority" (and maybe
"label:Android=HighPriority" as a shortcut). By
namespacing things in this way, the user gets priority when
searching. It starts simple for the user, and gets more
complex only as they expand their world out.

While it is possible to acheive similar searching usecases
by manually deviding the global namespace, maybe like
"label:/Users/self/important", "label:/Users/Joe/important",
and "label:/Groups/Android/HighPriority", this requires each
installation to come up with such a scheme (consistency
likley suffers), and it still requires admins and extra
Gerrit code to somehow define an ACL scheme to manage labels
this way (project/refs ACLs can't do it). This extra ACL
code would need to be written and would provide very little
extra utility over a builtin user/group split.

> How should a user choose the label group in a way that
> makes sense in an LDAP-world where every user is
> part of 100s of groups?

I am not sure I understand your concern here. Maybe my
picture above helps outline better how I envision group
labels being used? I picture that everyone can see public
group labels, but that users can only apply group labels if
they are in that group. So if I want to apply the
"HighPriority" label for the Android group (and I am in that
group), then when adding a label in a text box, perhaps I
type "Android:HighPriority" and then hit "add". Does this
still seem unmanageable?

> I understand the need for a users to have private labels
> to help organize themselves, but since private labels are
> not one of the more prioritized business cases for us,

I am not sure you are using the term public/private the way
I am. The public/private concept I outlined is not about
namespacing or editing, but rather about visibility (so it
is secondary to the namespacing concept).

I appreciate that "shared" (what you likely meant by public)
labels are more important for your current business case,
and don't expect you to change that. It meets the needs
that you have today. I am simply leary of such an
implementation in Gerrit because I think it has limited
appeal to many others, especially to those with servers with
unrelated teams/projects. I propose that if "shared" labels
are more important, that perhaps the group label concept
could fill that need (even if a bit more than what you need)?
And in that case, to get what you need quicker, maybe the
group label concept is something that could be implemented
before user labels?

> I have a proposal; My suggestion is that we develop a
> public label system similar to what we proposed using the
> ACLs (some Leads/Teams/Projects may want to reserve the
> labels for themselves on certain refs, without other
> users interfering) and store them in the
> project.git/changes/ namespace, similar to how approvals
> will be handled in the NoteDB.

Could you outline a use case in which reserving labels using
project/refs ACLs would be particularly usefull in light of
the search issues I mentioned in my previous email? Would
you be trying to use these ACLs to limit visibility or
editing?

[Magnus Bäck]

On Monday, August 11, 2014 at 16:51 CEST,
"Lundh, Gustaf" <Gustaf...@sonymobile.com> wrote:

[...]

> > (I will use the term labels to disambiguate from git tags)
>
> And I will too.

On the other hand "label" is also "taken" in this context, but other
synonyms like "attribute" and "property" don't sound quite right.
Never mind "trait".

[...]

--
Magnus Bäck | Software Engineer, Development Tools
magnu...@sonymobile.com | Sony Mobile Communications

[Selberg, Sven]

I would like to start off with addressing the naming issue, 'label' is really not a good name since it's already reserved.
We have discussed the following alternatives:
* Stamp
* Mark
* Marker
* Keyword
Thoughts around these and/or other suggestions are more than welcome.

Because of the 'label' ambiguity I've chosen to call it 'stamp' in this reply.

>With the global namespace solution I think these problems are being delayed to later be solved by every Gerrit installation.

I can't see how these problems would manifest themselves to the same extent with global stamps!

1. Reading stamps in the GUI; only thing that would be visual on the change screen would be a list of the stamps for the change in question.
1.1 Yes, without namespaces you would be presented with every stamp created for this change, but for a very buzy change a rough guess is that it still would amount to around 20 stamps. With a list that displays the top 5 stamps and leaves the rest open for inspection after expansion of the "box" it would not clutter the UI to any greater extent.

2. Adding a stamp; would be a simple matter of writing a string in a text field and pressing enter.

3. Sorting on a stamp would be as simple as 'stamp:important'. If you are part of a feature development project that span over several git:s, you probably have a stamp for that to. To sort out the important changes for this project it would be as simple as 'stamp:important and stamp:our-cool-project'.

Our concerns with the group/users goes beyond cluttering the GUI. It would plain and simple not be as useful as global stamps.
I.e. If you want to create a group stamp for a specific subset of users you would first have to traverse literally hundreds of ldap-groups to find a group that fits the bill, if you would ever find one. This would create an over-head that would make users refrain from using stamps at all and the feature would lose all value to us.

>Could you outline a use case in which reserving stamps using project/refs ACLs would be particularly usefull in light of the search issues I mentioned in >my previous email?  Would you be trying to use these ACLs to limit visibility or editing?

I see no search issues with the global stamp approach. As far as ACLs goes we are only interested in preventing Create, Update, Delete of Stamps for specified refs (perhaps release branches etc). Read rights is not a major issue as far as we can see. Reserving the use of specific stamps turned out to be rather cumbersome to implement with respect to the value it would add.

To conclude:

I see no reason why this cannot be implemented in increments. If we first create a global stamp support which, as far as we can see, could fulfill the widest array of use-cases, support for individual/group private/global namespaces could be added later on. If the global stamp feature does not add any value to certain Gerrit instances it would be a simple matter of disabling them through configuration, and wait for the feature to be developed further (or invest in developing it further themselves).

As Gustaf has already stated, we can't invest in developing a feature that does not fulfill our use cases and that is far more complicated than the feature that does. We put this feature on hold the first time around, as opposed to implementing it in an internal plugin, since we see great value in contributing it to the whole Gerrit community (because we regard it to be a great feature).
If this feature gets stuck because of an overly complicated development plan, even though it should be possible to implement the global parts now and possibly evolve the feature to include namespaces in the future if needed, our only way forward would be to go with an internal plugin. This would leave us with an equal or lesser investment in development time and assure that we get the feature we want (for instance, we could just add another table in the POSTGRES and skip the new cool NoteDB stuff), on the other hand the community would not benefit from our investment and it would go against our principles of contributing everything back to the community.

Your truly
Sven Selberg

-----Original Message-----
From: Martin          Fick [mailto:mf...@codeaurora.org]
Sent: den 11 augusti 2014 23:18
To: repo-d...@googlegroups.com
Cc: Lundh, Gustaf; Selberg, Sven
Subject: Re: Labels/Tagging Feature - Reloaded

[Thomas Swindells (tswindel)]

I agree with Sven's analysis here. It depends on how people plan to use them but I can't see any major issues with just having a global stamp/label namespace. For generic stamps like 'important' I doubt anybody would be searching on that stamp value alone (they'd combine it with a project operator or another label), and if I personally really wanted to label up the change which I think is important to me (ignoring the fact the star marking already exists) I will quickly decide to use another stamp (ImportantToTS).

I'd therefore strongly support the keep it simple and quickly implemented and then once people start using it see whether they really need stamps for groups, private stamps and permissions etc and whether the advantages of having those really justify the extra work.

Thomas

[Deniz Türkoglu]

Little late the discussion here, we are experimenting with a new commit message format that has tags and I think they are perfect match.

What we are doing is basically adding hashtags to commits so we can parse out data as we need;

Tags: #build, #new

Issue: AND-123

Change-Id:...

Using this a script can automatically create a change log for instance. I think it would be great not to lock such a feature to gerrit and keep it really simple.

Suggestions?

-deniz

[Lundh, Gustaf]

Hi Deniz,

 

Long time no see :)

 

> I think it would be great not to lock such a feature to gerrit and keep it really simple.

 

Perhaps I am misunderstanding you; Could you please elaborate? Do you mean that this feature is not a good match for Gerrit? I would certainly want to be able to add this kind of easy/searchable metadata without editing the commit message (adding patchsets) to update #tags. What happens if you want to add #tags after the commit is merged?

 

Best regards

Gustaf

[Zu, Bruce]

Is it bad to call it ‘mark’？
/Bruce

[David Ostrovsky]

Am Dienstag, 19. August 2014 10:26:27 UTC+2 schrieb Gustaf Lundh:

Hi Deniz,

 

Long time no see :)

 

> I think it would be great not to lock such a feature to gerrit and keep it really simple.

 

Perhaps I am misunderstanding you; Could you please elaborate? Do you mean that this feature is not a good match for Gerrit? I would certainly want to be able to add this kind of easy/searchable metadata without editing the commit message (adding patchsets) to update #tags. What happens if you want to add #tags after the commit is merged?

What happens if Gerrit users that don't enforce review policy, allowing to bypass gerrit

review branches, would also want to benefit from this feature? If i've understood your UI

suggestion right, Gerrit in unaware of this changes at all, so how tags should be changed

for these changes? Can we really ignore this use case? As i've understood from the last

Gerrit User Conference, tons of Gerrit power users don't enforce review policy on their

projects (ask Edwin, for example).

[Deniz Türkoglu]

Hi again Gustaf :)

I think the feature is really nice and a great match for gerrit. Adding hashtags after merge is not something we thought about and I am not sure it will be needed, since you guys have been using it for a long time maybe you have a different experience?

The good part about having the info in the commit is that it's directly visible in the log without the need for gerrit.

cheers,

-deniz

[David Pursehouse]

On 08/19/2014 06:00 PM, Deniz Türkoglu wrote:
> Hi again Gustaf :)
>
> I think the feature is really nice and a great match for gerrit. Adding
> hashtags after merge is not something we thought about and I am not sure
> it will be needed, since you guys have been using it for a long time
> maybe you have a different experience?
>
> The good part about having the info in the commit is that it's directly
> visible in the log without the need for gerrit.
>

Why not have both? I.e. the feature as described by Gustaf, and then on
top of that a configuration option that allows the 'stamp' to be pulled
out of the commit message according to a given pattern. For the case
you mention, it would be configured to recognise the hashtag format.

[Deniz Türkoglu]

Sounds good. I suggest doing it by pulling it out of commit message as first step, the main idea behind this is to not lock the feature to gerrit and gerrit UI. If it's a plugin, and the support is there, it would be very easy to extend it and add feature flags depending on individual needs.

[Lundh, Gustaf]

No, I guess people that only push to refs/heads/* would not benefit as the feature is described today. And since you cannot search/query Gerrit for commits that is not tied to Changes/PatchSets, the usability of the “stamps” would quickly diminish regardless.

 

> Can we really ignore this use case?

 

Personally, I think we can. This is an enhancement of the review parts of Gerrit. It is there to help classify changes and for users to structure their review workflow. I don’t really see the need to be able to apply stamps to all commits, but I would certainly be happy to get some more inputs on this.

 

/Gustaf

 

 

From: repo-d...@googlegroups.com [mailto:repo-d...@googlegroups.com] On Behalf Of David Ostrovsky
Sent: den 19 augusti 2014 10:46
To: repo-d...@googlegroups.com
Cc: de...@spotify.com; tswi...@cisco.com; Selberg, Sven; mf...@codeaurora.org; Luca.Mi...@gmail.com
Subject: Re: Labels/Tagging Feature - Reloaded

 

--

[David Ostrovsky]

Am Dienstag, 19. August 2014 15:20:51 UTC+2 schrieb Gustaf Lundh:

No, I guess people that only push to refs/heads/* would not benefit as the feature is described today.

I think wording "only" in this statement is wrong. By not enforcing review policy by project in this context meant the

change owner may or may not bypass review branch for specific change at hand. That's her decision: if she thinks

it is harmless change she may bypass the review (well we know, that always the trivial changes that always break

master). In practice, for many projects that means, that you have 30%/70% (or other way around) relation between

changes.

As you described the feature, UI and Lucene integration: 70% of all changes in such projects aren't

stampable and only 30% are. Is that what you want? Does it make sense?

 

And since you cannot search/query Gerrit for commits that is not tied to Changes/PatchSets, the usability of the “stamps” would quickly diminish regardless.

How it is currently implemented, i guess you are right, but every implementation can be changed.

[Selberg, Sven]

Hi,

 

“Gerrit in unaware of this changes at all”

I’m guessing you are referring to commits here.

This suggests to me that you think it is necessary to implement the ‘stamp’ support on a commit level. In the eventuality that Gerrit, in the future, might become aware of all commits in the repositories. Since Gerrit must be aware of non-change-commits in order for “stamp”s for these commits to be useful in Gerrit. Are there any plans for gerrit to become  aware of all commits?

This feels like a quite huge implementation. I would dread running reindex on our instance if all commits would be indexed, it would probably take days.

 

“What happens if Gerrit users that don't enforce review policy, allowing to bypass gerrit review branches, would also want to benefit from this feature?”

What other Gerrit feature except for the ACL, stream-events and replication are they benefiting from today when they bypass review?

If you bypass review you are practically using Gerrit as a git-daemon.

 

“Can we really ignore this use case?”

Well, whoever chooses not to use the full power of Gerrit probably made a educated decision not to do so. There are other useful features that they have chosen not to use.

 

“As you described the feature, UI and Lucene integration: 70% of all changes in such projects aren't stampable and only 30% are. Is that what you want? Does it make sense?”

Presently you are not able to comment on ~95 percent of the commits in our gits through Gerrit, and you can’t display them in the side-by-side view either.

 

“How it is currently implemented, i guess you are right, but every implementation can be changed.”

Amen to that!

However you must weigh the probability of those changes taking place, the effort and cost that is needed to take height for them and the complexity that such concerns introduces to the code base.

 

Last but not least:

The feature that we proposed is on a change-level, because that matches our use cases. Bringing this feature to a commit level does not.

Even if it would be decided to implement a stamp-support on commit level. To fulfill the use cases, we have brought forth in previous emails, would call for a way to force these ‘stamps’ to behave as if they were on a change-level.

 

/Sven

 

From: repo-d...@googlegroups.com [mailto:repo-d...@googlegroups.com] On Behalf Of David Ostrovsky
Sent: den 19 augusti 2014 15:47
To: repo-d...@googlegroups.com
Subject: Re: Labels/Tagging Feature - Reloaded

 

Am Dienstag, 19. August 2014 15:20:51 UTC+2 schrieb Gustaf Lundh:

No, I guess people that only push to refs/heads/* would not benefit as the feature is described today.

>What happens if Gerrit users that don't enforce review policy, allowing to bypass gerrit

>review branches, would also want to benefit from this feature? If i've understood your UI

>suggestion right, Gerrit in unaware of this changes at all, so how tags should be changed

>for these changes? Can we really ignore this use case? As i've understood from the last

>Gerrit User Conference, tons of Gerrit power users don't enforce review policy on their

>projects (ask Edwin, for example).

 

>I think wording "only" in this statement is wrong. By not enforcing review policy by project in this context meant the

>change owner may or may not bypass review branch for specific change at hand. That's her decision: if she thinks

>it is harmless change she may bypass the review (well we know, that always the trivial changes that always break

>master). In practice, for many projects that means, that you have 30%/70% (or other way around) relation between

>changes.

 

>As you described the feature, UI and Lucene integration: 70% of all changes in such projects aren't

>stampable and only 30% are. Is that what you want? Does it make sense?

 

 

And since you cannot search/query Gerrit for commits that is not tied to Changes/PatchSets, the usability of the “stamps” would quickly diminish regardless.

>How it is currently implemented, i guess you are right, but every implementation can be changed.

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

[Phil Hord]

I think if this feature is implemented in the refs/notes space, you would have the best of all worlds: labels can be added locally; labels can be searched locally; labels can be applied after the commit is created; labels can be applied to merged commits; labels are not dependent on Gerrit; labels can be grouped by user, group, etc. What did I miss?

With the right sort of controls, I suppose most metadata could be considered special cases of the same space. Reviewed, verified, abandoned, open, branch, etc. Yeah, ok, maybe that's going a bit too far.

But I'm serious about the notes space. What's not to love?

Phil

P.s. for a minute i thought maybe this thing should be called a hash;  then I realized that's overloading TWO already common Git words.

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

--- You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Phil Hord]

On Aug 19, 2014 4:30 AM, "Zu, Bruce" <Bruc...@sonymobile.com> wrote:
>
> Is it bad to call it ‘mark’？
> /Bruce

It seems to me like this is so commonly called a "tag" in the rest the world (as in "tag cloud") that using any other term is going to cause confusion[*]. Of course we can't use "tag", but maybe something close like "flag", "f-tag", "g-tag", etc.

[*] Consider the confusion for new and casual users around "merge" and "submit";  "commit" and "change"; "spin" and "patchset"; and so on.